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ABSTRACT 


The two main approaches towards a general 
programming language processor viz . , the syntax- 
directed and the macro-processor approaches, have 
been critically examined. A new approach using 
decision tables for displaying syntax and decision 
tables in conjunction with a set of canonical 
actions for specifying semantics of programming 
languages has been presented. The problem of 
mechanical translation of syntax has been considered 
and a simple algorithm for translating syntax speci- 
fication in the form of state graphs to decision 
tables has been suggested. 
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IITRODUGTIOH 


The increase in the applications of computers 
has been phenomenal over the past decade and half. Prom 
numerical computation to analytical manipulation of mathe- 
matical expressions and from symbol manipulation to speech 
recognition, the spectrum of computer applications is 
enormously wide. Apart from their breadth, these applica- 
tions, coming from numerous different problem environments, 
are verj diverse in nature. The computer being a rigidly 
monolingual machine, the demand for new translators which 
can present a problem-oriented interface to the user (by 
way of programming languages) has been constantly 
increasing. 

The writing of such a translator consumed 
several man-years in the early stages of computer evolution 
and persistent efforts have brought this down to several 
man-months. Pevorthaless the gap in time between the 
conception of a programming language aid its implementation 
has remained wide enough to discouiage any experimentation 
on the foimer and at times render a concept stalecby the 
time it is implemented. Besides, the complete machine- 
orientation of the conventional translator has not only 



rendered itself useless for other machines, but it has 
also resulted in any attempt to modify it (to introduce 
new features in a programming language), becoming a 
Herculean task. 

The realization of the aforesaid features has 
motivated several research workers to attempt a general 
programming language processor to which the description 
of a source language and its translation (into a given 
machine language) can be fed as input whereupon it acts 
as a compiler for that source language. The interest in 
this approach has been so great that the literature is 
replete with accounts of efforts in this direction. A 
considerable portion of these efforts have borrowed models 
from linguistics to describe programming languages. The 
inherent inadequacy of these models to provide a complete 
description of programming languages accompanied by the 
penchant of research workers for formalization has resulted 
in the general programming language processor being well 
above the comprehension of the average programmer. 

In this thesis, we have attempted to present a 
pragmatic approach towards a general programming language 
processor, using decision tables. Decision tables have a 
simple tabular structure which assists in a precise and 
readable presentation of decision-making procedures. What 



makes decision tables active documentation devices is their 
amenability to be translated directly into computer programs. 
Thus we contend that a general programming language processor 
usiig decision tables can be flexible, efficient and readable 
at the same time. 

?/e now present a brief account of our approach. We 
have demonstrated the feasibility of displaying a given 
syntax specification in the form of decision tables. This 
not only facilitates readability and extendibility , but it 
also provides scope for an efficient machine implementation. 

In ary pure syntax-directed approach, specification 
of semantics becomes a bottleneck since there is no standard 
metalanguage for specifying semantics. We have circumvented 
this problem by using a set of canonical actions in conjunc- 
tion with decision tables. These canonical a ctions represent 
the basic functions that a computer can perform and thus Pi- 
cons titute the most natural form of specifying the semantics 
of programming languages . 

To retain the advantages of a natural form of 
syntax specification and efficiency of machine implementa- 
tion (which are conflicting in their requirements), we have 
suggested the conversion of the former into an intermediate 
form by hand. Choosing state graph as this intermediate 



form, we have presented a simple algorithm which transla- 
tes this into decision tables. By thus standardizing the 
specification of a translator in terms of decision tables, 
we felt that a common efficiency criterion for general 
programming language processors could be worked out. 

Bor illustration purposes, we have programmed a 
small compiler for a limited subset of BORTSAB IV using 
decision tables embedded in BORTRAH IV (a translator 
for which' is available at our computer centre). Recogni- 
tion of syntactic units and specification of semantics 
have been displayed by decision tables. Beasibility 
being the main motivation, the effort lacks detail. 
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AN OVERVIEW OP SYUTAX-DIKEC-TED GOIgimS 

1 .1 INTRODUOTIOM 

Ever since Irons' historic paper (IS.0NS61), the 
syntax-directeu compiler h^ been the cynosure of research 
workers in the area of programming language processors. 
Numerous accounts of efforts towards this (so called) 
universal processor for programming languages have appeared 
in the literature. Eeldman and Gries (EEED68) have made an 
exhaustive coverage of these efforts in a review paper. We 
feel that we cannot surpass them either in their experience 
or in their meticulous coverage of the work in this area. 

So we do not intend to duplicate their effort by attempting 
another state-of-the-art survey. However, since in this 
thesis, we suggest an approach towards a general programming 
language processor (which is not devoid of the ccncepts used 
in syntax-directed compilers), we present here four typical 
efforts in this area. We elaborate (somev^hat critically) 
on two efforts in particular viz . , the use of Post's 
canonical systems in (D0N67) and the parse— edit machine in 
(EEEV ) since we feel that the first one has a sound 
formalism and the second one is a maiden suggestion to 
realize the syntax-directed compiler in the form of a special 
purpose computer. 
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1 -2 SOI^^ TYPIGAL ATTEMPTS TOWARDS THE SYFTAX-DIREGTEI) 
COI"TPILER 

1.2.1 OOypILER-GOKPILER OE 3R00KER, MORBIS, ET Al . 

The compiler-compiler of Brooker and Morris 
((BROOK67), (ROSE64) ) is one of ihe earliest attempts made 
in this direction. In the notation of this system, a 
phrase is a string of elementary symbols or class identi- 
fiers; a phx-ase class is defined in a form similar to 
Backus-Raur Form (hereafter abbreviated as BRE) . A format 
class is similar to a phrase class, with the distinction 
that each format in a format class has an associated 
format routine . The format routines and the associated 
source statement formats are the generators which actually 
control translation and other compiling operations. Certain 
basic stat ement formats for manipulation of numbers, 
temporary storage, indices and data structure at the 
translation level are built into the system; other 
auxiliary statement formats may be written using the basic 
statements and previously defined auxiliary statements. The 
format routines themselves are written in the language 
defined by the basic and auxiliary statements. 

A compiler is built up on this structure by adding 
format routines, each a list of statements in formats 
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already in the system, in a macro-build ing fashion . With 
enough source statement formats added, the system will act 
as a compiler for the language so described. The compiler- 
compiler has been successfully used to produce several 
compilers which a re compared with their hand-coded counter- 
parts in (BROOK67b). 

1.2.2 miDmirS BOHMAL Sa.!LAI^TIC lmgrage 

Beldman (PELDbb) has introduced a semantic 
metalanguage known as Formal Semantic language (abbreviated 
hereafter as F3L) which he uses to automate the postsyn- 
tactic:. aspects of compiler-writing. The syntax is 
described in a production larguage, which is based on a 
recognizer with a single push-down stack. As each character 
is scanned, it is placed on top of the stack and the first 
few elements are scanned by the productions which describe 
the source language. The production statements are 
formatted in five fields -- a) A label b) A "picture" of a 
stack configuration which is the pattern tested against the 
stack. The rest of the production is executed if a' match 
occurs; otherwise the next production in sequence is tested 
c) A second (optional) "picture" of .the stack configuration. 
If this field is non-empty and a match occurs in (b), the 
stack is transformed to this pattern at the end of execution 
of this production d) An indication of semantic action to 
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taketi". this may .call for the executton Of a semantic 
routliia, an error indioation or 'termination of compilation 
i) $he label of the next production to be compared to the 
itack., along with (optionally) a request for the next Input 
dharaGter to go into the stack-. 

The semantic routines are written in the formalism 
ISli. and are phfsioally separated from the productions. An 
S'SS program consists of two sections viz.> a declaration 
part and the main body. The declaration part describes the 
storage to be used by the translator, which may include 
cells-, constants,, tables and stacks. The body of the 
program consists of semantic descriptions of individuai 
constructs Of the source language. The basic unit is a 
labaliad statem#a%i the label foaMas the link to the prod u~ 
langu-age'. A -clear distinction is made between 
comp tle-“- time aotlons and .run-ti-me actions the I'atte’r being 
enclosed between ' OODS( ' on the left, and on the right. 
■The s%at,eme.nt types of TS'l include most -of the coiim'Qn 
C'Ons'tnucts of .programming languages-. A statemen t c-aBaaists 
of -a Series of commands, each of which may be a,) An a-sslgin-. 
■ment, statement b) An 'Operation of an elem.aa't ©f the 'data- 
Str-UCtuiO. (eg-. t:.abl®*-iL'OC!feUtp-!^ C:|; A transf-er' of eon-troi. 

'd'l- A oall ‘On a system macro e;| A. G®n>d:i.t.l4ma'l 

aind almost any of the above in CODE, brackets to I'Micfate 
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run-time execution. The formula ALGOL group at Carnegie 
Mellon UniTersity, Pittsburgh has made extensive use of 
PSL to produce several compilers (ITUE66). 


1*2.3 USE OP POST'S OAMIQAL SYSTEMS BY LOIIOVAI AMD 
LEDGABD 

Donovan and Ledgard (DOE'S?) have presented a 
scheme for specifying the syntax and translation of computer 
languages using Post's canonical systems. Their scheme has 
evolved from 1he theory that canonic systems can be used to 
specify any recursively enumerable set. They have used 
canonic systems to define two examples of recursively 
enumerable sets viz., the set of syntactically legal 
programs comprising a computer language, and the set of 
ordered paixs specifying the translation of programs in 
one language to programs in another, '^ii'e include here an 
example from their report to illustrate the scheme. A 
subset of PL/I was chosen by the authors for the definition 
of syntax and translation into IBM System/360 assembly 
language. The syntax of a "GO TO" statement is expressed 
as follows; 


1 label 


j— GO TO 1 ; go to stm with ref label _1 , label var /\ 


This canon can be informally read as : 

If 1 is a member of the set "label", then "GO TO A;" 



is a member of the se;t ’’go to stm with ref label 1 and 
label var A (null)". 


To include the translation into 360 assembly language, the 
above canon is modified as : 


1 label 


GO TO 1; go to stn with ref label 1 


vars A 3®® stms B 


* BBANGH TO 


label 

1 


The authors contend that the proposed scheme can 
account for the con tex- sensitive features of programming 
languages (eg. No two statement labels should be the same; 
No variable should appear in more than one declaration and 
so on) which phrase structure grammars and BNP cannot 
account for, fe feel however that this point has not been 
given as much emphasis as it deserves. Canonic systems 
appear to be a good scheme with explicit provision for 
context-sensitive gramnisrs and hence constitute a prag- 
matic formalism. The authors' statement that BNP coupled 
with "a few Ei:iglish sentences" provides a concise descri- 
ption of languages is truly amazing. Conciseness, though 
an undisputed virtue, should not be at the expense of 
relevant details. We do not share the authors' belief 
that canonic systems will not replace BNP to describe 
programming languages to "people". The feasibility of a 
formalism for describing programming languages that can 



appeal to the lay user is very doubtful in the light of 
the numerous attempts made so far- 

Canonic systems provide a precise and uncluttered 
way of describing programming languages. Though they 
incorporate semantics along with syntax, features like the 
presence of messages in the generated code ensure that 
readability is not impaired. However there seems to be 
some difficulty in implementing operator precedence. In 
the scheme suggested by ‘the authors, addition and subtrac- 
tion are carried out in separate registers from multiplica 
tion and division. Such a procedure would prove very 
inefficient on a machine with a single set of registers 
(Accumulator and Fultiply Quotient) for arithmetic 
operations. In as much as this is an instant-code 
generation scheme, aiiy code optimization can be attempted 
only at assembly level. 

The scheme has not yet been implemented in full 
detail. Since this scheme with i ts intrinsic clarity and 
precision is likely to appeal to the formal linguist as 
Y^ell as the informal programmer, we feel that such an 
implementation will be worthwhile and will enable one to 
assess the tme merits of the scheme. 



- BEEVES* PAESE-EDIT JU.OEim . 

Seeves (EEEV67) has simulated a parse-edit 
machine in ilGOL on a ICDPg computer. The machine simula- 
ted is a special purpose stored program computer which 
acts as a syntax-directed translator. A program for this 
machine represents the syntax and semantics of a given 
source laiguage. The machine reads as data, under contro] 
of its program, a text allegedly written in the source 
language. If the machine finds the source text syntacti- 
cally legal, it produces an outpit determined by the 
semantics of the souxce laiguage* 

The author brieves that "students and teachers 
of computer science may find it of value to have readily 
available facilities for practical experimentation in the 
definition and manipulation of formal languages". In the 
light of this belief, one would expect two features from 
this paper - a) A clean and precise formalism for expres- 
sing syntax and semantics, and b) A discussion of the 
pragmatics involved in the realization of the machine 
proposed. However, to one’s dismay, one can find neither 
of these features in the elaborate presentation. This will 

be evident as we review some of the important aspects of 
the paper. 
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Though the author has retained BNP with minor 
modifications for expressing syntax, he insists on proving 
that this metalanguage is capable of describing itself. 

The result is a clumsy notation in which one has to spend 
considerable time in distinguishing between metasymbols 
and actual symbols in order to grasp the intent of the 
productions. We quote here one of the productions 
presented in Section 2 of the paper; 

•Cvariable^ = <'* =\ • 

\ ^ 

This can be infoimally read as - "A variable is defined as 
a follov/ed by a sequence (including none or many) of 

symbols other than ")> " followed by a This pains-, 

taking exercise does not throw any new light on the meta- 
language proposed. It has been realized in (DON67) that 
no metalanguage proposed hitherto is capable of expressing 
the syntax of any arbitrary source language. The author’s 
desire to have"a more formal and compact definition” is 
another instance of forcialisation at the expense of 
elegance and readability. 

In Section 3 of the paper, the author introduces 
some of the operation codes of the parser machine. Also 
provided is a tutorial exercise in defining an "unsigned 
integer" whose contribution towards understanding the 
parser machine can be seriously d oubted. The 


parser machine 
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has two subroutine cue ana link instructions, three 
conditional juiap instructions, three input instructions 
and one output instruction. Two ezemples are worked out 
using these instructions and they are self-ezplanatory . 

In Sections 4, 5 and 6, the author outlines a 
scheme for the automatic conversion of the metalanguage 
into the machine code cf the parser machine. He introduces 
a number of edit codes which are to be sui.tably embedded 
in the metalanguage program describing thesyntax of a 
source language. It is precisely these eait commands 
that introduce the semantics of the source lai^uage in 
its syntax specification. To accomplish the autcmatie 
translation of metalanguage, the parser machine is extended. 
The parser machine parses an input string of the source 
language and if it is syntactically legal, it' produces an 
output which comprises source language symbols inters- 
persed with edit codes. At this point, the editor machine 
takes over. It interprets the edit codes and takes 
suitable actions. The output of the editor machine will 
be the translation (in a target language) of the source 
language text. For the sake of clarity, we li st out all 
the steps involved as follows ; 

a) Input the specification (of the syntax and semantics) 
of the source language in- the metalanguage to the 
• extended parser machine. 
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b) The extended parser machine produces an output in its 
machine code, which is in effect the compiler for the 
given source language. 

c) Input the program produced in (b) to the extended 
parser machine. The data to this program is a text 
written in the source language - 

d) The extended parser machine produces a symboloc output 
interspersed v^ith edit commands. 

e) The editor machine (initiated by an TIDIT W command) 
scans the output stream produced in (d) and executes 
all the edit commands. The resulting output is the 
translation (in a target language) of the source 
language text. 

Sections 7 and 8 introduce some edit codes 
amidst a profusion of detail about the assembly language 
and its implementation. It is annoying to find these 
details jeopardize the sequence of the important aspects 
of the scheme presented. The edit codes presented here 
perform internal number conversion, name searching and 
bit selection. Sections 9 and 10 dwell upon some aspects 
of the simulator. • , 

We sum up hero our impressions about the scheme. 
As the structure of the machine to be used is not imposed 
a priori (as is the case in practice) there can be 



considerable flexibility in the design of the formalism 
for describing the syntax and the semantics of source 
languages. We feel that the author has not exploited 
this significant 'idfeature. Consequently, as far as the 
user is concerned, the existence of a separate machine 
for syntax-directed translation does not in any way 
simplify his task of describing a desired language. One 
would compromise to such an inconvenience provided that 
the machine suggested is either amenable for easy imple- . 
maitetion or if it supersedes other existing syntax- 
directed translators in terms of efficiency. One finds 
no comment on either of these aspects in the paper, though 
having written the simulator, the author is best equipped 
to venture it. 

Though the author confesses at the outset that 
his account of the scheme is "rather detailed though 
deliberately elementary", the deliberation on some 
occasions far supersedes one's expectations and clouds 
the issue being discussed (vidse Section 3). An orderly 
description of the parse and the edit machines followed 
by examples for subsets of well-known languages would have 
been more instructive and comprehensible than the meta- 
grammar presented in Appendix 2 of the paper. Also some 
of the details of assembly could be dispensed with since 
such techniques are well established and published. 
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1.3 SOME REI#.M;S on the syntax-directed OOMPIIER 

In spite of the tremendous energies expended on 
it, the syntax-directed compiler has failed to cross the 
boundaries of the research worker's cell. This can be 
traced back to some (a-void-able) features that hare charac- 
terized the work in this area. Eirstly, most of the attempts 
have been pedantic rather than pragmatic in their approach, 
giving undue importance to formalization sometimes at the 
expense of detail. One cannot otherwise explain the per- 
sistent usage of models like the phrase structure grammar 
which have been provod to be inadequate for syntax expres- 
sion (GHOM63). Secondly, little attention has been paid to 
the realization of algorithms for translating syntax and 
semantics to make the resulting compilers efficient. In 
the absence of this, the commercial world of computer 
manufacturers would be content with their efficient hand- 
coded compilers. Thirdly, most of the efforts have been 
isolated in nature. As a result, the ingenuity of one has 
not been exploited b,.y others. Eourthly, there has not bean 
the slightest attempt to standardize the formal notation 
being used. This may cause the switch-over of the user 
from one syntax-directed compiler to another to be so 
difficult that he may prefer to use an existing programming 
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language. I'inally, as a compound result of the above 
features, the possibility of a common efficiency criterion 
for syntax-directed compilers is remote. The fact that 
there i s no such well defined criterion for conventional 
compilers does not eliminate this problem.. 



CHAPTER II 


THE MACRO-PROCESSOR APPROACH TO 
TRAHSLATOR WRITIIG SYSTEMS 

2.1 IHTRODUCTIOI 

The idea of a general processor for prograniiiing 
languages has been pursued by two schools of thought - one 
taking the syntax-directed approach and the other taking 
the macro-processor approach. It behoves us to confess 
here that we are not trying to present the case for the 
macro-processor approach (Halpern (HA168) has already done 
this with considerable vehemence), have attempted to 

present the highlights as well as the drawbacks of this 
approach as applied to the realization of a general 
processor for programining languages. Our intent in this 
presentation will become clear in later chapters where we 
suggest an approach which in effect is a combination of the 
syntax-directed and macro-processor approaches.' 

2.2 EARLIER WORK OH THE MACRO PROGESSOR APPROACH 

Expositions of the use of macros as a tool for 
compiler-writ irg have appeared early in the literature. 
Bennett and Neuman (BETM64) discuss a scheme of extending 
compilers by using macros and string concatenation. The 
macros describing the new features to be added to the source 
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language are arranged at the beginning of the source deck. 
The authors illustrate this with macros which can extract 
a given portion of any machine word. It is suggested that 
this feature could be utilized in comnuni eating between 
separate programs. 

2.2.1 FERGlSOh'S META -ASSEMBLER 

Eerguson (EERG66) ' introduces the concept of 
raeta-assenblers. This cancept has arisen from the 
realization that all^ assemblers have many features in 
common. By building procedures for handling such things 
as symbol tables, location counters and macros, one could 
speed up the writing of particular assemblers. The input 
to the meta-assembler comprises the word size' of the machine, 
internal number representation etc. The output of the 
meta-assembler would be an assembler for the given machine. 
Eerguson further says that the meta-assembler could be used 
in the role of a compiler also by providing certain 
additional features, since there is always an overlap 
between the facilities required by an assembler and a 
compiler - eg. Stacks, Table-lookup etc., Eor instance 
consider the (source) statement : 

IE E(A) PLUS 5 EQ G(B) GO TO 1 

Eor enablj,ng the meta-assembler to handle this statement, 
Eerguson Jiiggests a scheme called' many-many macro in which 
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IF, PLUS, SQ and GO TO are defined as prefix operators. 

The nany-raanj roacro has features for using and updating 
state information during text replacement. It has 
potential applications in compiler -writing since it can 
handle a sentential form completely. One cannot cominent 
on the efficiency of this scheme since Ferguson does' not 
present any details of implementation. 

2.2 MGILIOY'S BXTEEDIBLE G agllER 

Mcllroy (MGII60) is one of the early advocates 
who suggested macros as. a wholesome tool for compiler-'wri ting. 
He emphasizes that powerful compilers can be built from a 
small set of functions (primitives). He illustrates this 
for the case of algebraic translation. The main advantage 
claimed by him for macros is the "definitional extension" 
of a source language. The primary requirement for such an 
extension is that the scanner of the compiler be appended 
to accept new source language statements. Mcllroy has 
worked out an example showing how this can be achieved 
for variable field scanning which is commonly used in 
compilers. His remark that statements effective at object 
time should have counterparts effective at compile-time is 
very significant. If this; is realized, the interpretation 
of source statements could be implemented with ease and the 
problem of semantics is solved to a large extent. 
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2.2.3 HALPEM'S ?0M ON THE MGRO-PROGESSOR APPEOAOH 

Halpern (HAL68) is the most vociferous proponent 
of the macro-processor approach. We first msiition here some 
features of the system XPOP (HAIi64) which he has developed. 
In a language implemented on this system, any statement is 
a call on a macro written in IBM? 090 assembly language. The 
system assumes the responsibility of recognizing Ihe macro 
calls (eg. GO TO, IP, BO etc.-) which occur in source 
statements. The punctuation of a source statement can be 
specified as a set of parameters in the macro by which it 
is to be regognized. This ensures flexibility in the format 
of source statements. A macro definition can specify noise 
words which are to be ignored and keywords which are to be 
retained. Thus the source language can have an English-like 
structure with a limited vocabulary. This is no small 
advantage for a. lay user:^ ofi-ithe-sotirce language. 

Por the implementation of source languages, XPOP 
offers certain elegant facilities. It allows the compiler- 
writer to defer code generation from a part of the source 
program until some criteria (specified by the programmer) 
are satisfied. This is useful in compiling BO statements. 
Purther the system has a number of trace and debugging aids 
which would be of immense help in checking the compiler. 
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Knowledge of the assembly language is indispensable 
for the user of XPOP. In this respect, XPOP resembles a 
conventional monolingual compiler. However the important 
difference is that the latter operates at a 'micro* level 
whereas XPOP operates at a 'macro' level. A good analogy 
would be the difference between electronic circuits made of 
discrete components and integrated circuits. In the fonaer 
case, one has to always start at a basic level no matter 
how complex the desired circuit is. In the latter case, 
one is given a set of carefully chosen modules which can be 
combined to realize the desii'ed circuit. Thus not only is 
the time spent on elaborate details at a basic level saved 
but the designer can aim at more complex and powerful circuits 
without the accompanying sacrifice of time and labour. 

XPOP appears vulnerable to implement AIGOL-like 
languages which have a high degree of structure (as observed 
by Feldman and Gries (FSID68)). The nesting of macro calls 
would be luite ixivolved in such cases. With the advent of 
third generation computers vvith hardware stack operations 
(eg. Burroughs B8500), this drawback may not be serious. 

In a subsequent paper (HAI168), Halpern-' makes a 
vehement attack on the opponents of the macro-processor 
approach. He brirgs out several significant points regarding 
the incessant quest for a general processor by numerous 
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research workers. Mth clinical expertise, he dissects the 
syntax-directed compiler in its present form and shows that 
the fault lies in the inadequate formalism around which it 
is built viz., the phrase structure grammar. However in 
his anxiety to defend the cause of the macro-processor 
approach, he tries to cloud some of the inescapable 
deficiencies of this approach (viz., machine oriented 
notation, redundant coding etc.). A more pragmatic stand 
would have been to concede these drawbacks and suggest;- 
possible remedies. We venture to make this attempt in 
the next section, 

2 . 3 PI SOU SSI OH OF THE T.'^AORO-PROCESSOR APPROACH 
2.3.1 APYAHTAGES 

We discuss here five important ac vantages of the 
macro-processor approach. We follow this up with a mention 
of its main disadvantages end possible means by which they 
could be obviated. 

a) Uniformity of the modus operand i 

The macro-processor approach offers a uniform 
technique for compiler-writirg . It has evolved out of the 
belief that a set of basic functions (premitives) can be 
used to build powerful compilers. Mdlroy (M0IL60) has 
stated this in one of the earliest papers on this approach. 
Without uniformity in approach, there can be no common 



ground on >.'vhich comparison cai^ be made among several 
attempts. In such a case, the collective progress in the 
area would be extremely slow however good the individual 
attempts may be. This is made evident by 1he fact that the 
numerous diverse attempts towards the syntax-directed 
approach (vyhich far outnumber those towards the macro- 
processor approach) have resulted -in .several good indivi- 
dual efforts.-which"because of their isolated nature have 
produced .very little interaction among their authors. 

b) Natural method of handling semantics 

In the syntax-directed approach, recognition of % 
a syntactic unit is a streamlined process but its inter- 
pretation remains a blockhead. (Several individual attempts 
have been made to overcome this problem but have failed to 
yield a coraiaon satisfactory solution). The gravity of the 
problem of semantics is magnified in the case of languages 
for symbol manipulation. For instance in SHOBOI "STRINGI 
STRING2 = ]6 STaiNG3". appears to be an innocuous 
statement whose syntax could be easily expressed in -BUF ' 
but its interpretation in English would run into several 
lines (and many more in machine code) . The primitives 
used in the macro-processor approach represent "actions” 
which the machine can perform. Thus they constitute the 
most natural tool for expressing the semantics of 
programming languages. 
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c ) Extendibility of compilers 

In Older to jneet the demard of new applications, 
progranming lerguages must have the capacity to evolve with 
time. The macro-processor approach offers ample scope for 
extending corSpilers. Efew actions could be defined in 
terms of the existing macros or new macros defined if 
necessary. 

d ) Possibility of approaching natural language 

As demonstrated in Halpern's XPOP (HAL64), 
restrictions on the format of source language statements 
could be considerably reduced vvith the aid of the macro- 
processor approach. Thus the source language could be 
brought n oarer to natural language. This has a far 
reaching effect on improving man-machine coimunication. 

Povv that computer time-sharing techniques are well 
established, the user has direct access to the machine. 

This "nearness” could be better exploited if the language 
of communication resembles natural language at least in a 
lii::!ited seiise. The computer would be more welcome vvith a ■ 
child's vocabulary rather than with an unnatural and formal 
adult vocabulary by the lay user. 

e) Efficiency of implementation 

The efficiency of the macro processor is largely 
dependent on how the assembler handles the macros and their 
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child's vocabulary rather than with an unnatural and formal 
adult vocabulary by the lay user. 

e ) Efficiency of implementation 

The efficiency of the macro processor is largely 
dependent on how the assembler handles the macros and their 
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nesting. Teciiniques to do this are well established and 
hence it is possible to have a cominon efficiency criterion 
for macro-processors. This would take us one step towards 
the elusive efficiency criterion for compilers. 

2.3.2 hRAWBAOgS AED POSSIBLE REMEDIES 
a) Object program inefficiency 

A macro is an open subroutine as a result of vtfhich 
repeated calls on it would result in the generation of 
redundant coding. This leads to inefficient object 
programs. This is the main objection of the antagonists of 
the macro-processor approach. We feel that this problem is 
not serious any more in the light of the following reasons. 

Recent trends in computer design tend to bestow 
on the user the liberty of building his own operation codes 
rather than give him an inflexible set of (standard) 
operation codes. Thus microprogramming has found its 
place in third generation computers. This being the case, 
the macro can be looked upon as a powerful operation code 
the implementation of which c culd be carried out at a micro 
level, rendering its execu ti on much faster . Then repeated 
calls on a macro would be synonymous with the repeated 
execution of an operation code in a conventional computer. 
Further hardware operated stacks (mentioned in 2.2,3) would 
facilitate the nesting of macros. 
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b) I'uachine dependence 

Macros are made up of the operation codes of a 
given machine and hence any system built around macros 
would be machine dependent. This is the other important 
objection raised against the macro-processor approach. 

The answer to this problem, we feel, lies in choosing a 
sufficiently large standard set of actions( which are in 
effect macro calls). Having agreed upon such a standard 
set, it only requires these actions to be coded ONCE for a 
given machine. We hasten to add that this does not solve 
the problem of machine dependence in its aitirety. The 
question always arises as to what should be done if the 
user requires new primitives. They have to be coded in 
machine language. We state (somewhat philosophically) that 
it is not perhaps possible to totally eliminate machine 
dependency from a compiler. However the solution sug; ested 
by us, we hope, reduces machine dependency to a considerable 
extent- . 

In conclusion, we contend that with the present 
state of computer technology, macros^- can be purged of 
their drawbacks while at the same time retaining their 
advantages. 



CHAPTER III 


DEGISIOH TABLE AS A TOOL EOR EXPRESSING SYFTAX 

, i 

3.1 IHTROEUCTION TO DEGISIOH TABLES 

3.1.1 STRUCTURE AMD EEEBTITIOHS 

Decision tables are a method of specifying 
a) the relevant conditions to be met in a given situation 
and b) the set of actions to be taken when these conditions 
are satisfied. The name ’Decision Table' has arisen since 
a decision-making procedure is displayed in the form of a 
table. An excellent introduction to decision tables is 
given in (KING67). Therefore we will only define the terms 
necessary for our discussion- 

Rule 1 Rule n 


Condition Stub 

1 

Condition ... 

. . . . Condition 



Entry 11 

Entry In 

Condition Stub 

IT! 

Condition ... 

, . . . C ond it i on 



Entry ml 

Entry mn 

Action Stub 1 


Action 

. . . . Action 



Entry 11 

Entry In 

Action Stub i 


Action ... 

. . . . Action 


i 

En try i1 

Entry in 


Figure 3.1 Structure of a Decision Table. 
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Figure 3.1 shows the structure of a decision table. 
A decision table has four quadrants. The upper left quad- 
rant contains 'Condition Stabs' which specify the conditions 
to be met. The upper right quadrant contains 'Condition 
Entries’ which specify the truth or falsity of the condition 
stub in that row. The lower left quadrant contains 'Action 
Stubs' which are the actions to be taken. The lower right 
quadrant contains 'Action Entries' which specify whether the 
action stub in that row is relevant or not. Each column in 
the combination of the right quadrants is called a ’Rule*. 
The significance of a rule is that when the conditions 
relevant in that column are satisfied, the actions denoted 
by the action entries are obeyed sequentially. 

Decision tables are of three types - a) limited 
Entry b) Extended Entry and c) Mixed Entry. In limited 
entry decision tables, the condition entries can be’Y(Yes), 
N(]Jo) or - (Don't care) and -the action entries for the 
actions pertinent to a rule are denoted by X. In extended 
entry decision tables, a part of the condition or the action 
can extend into the corresponding entry.,- In mixed entry 
decision tables, both of the above features are permitted 
the restriction being that a given row must contain only 
one type (limited or”* extended) of entry. 



3.1.2 ILLU.STHATIOH OP A PEOISION TABLE 


Por illustration purposes, we state a procedure 
for selecting a team of cricket players and display the 
procedure in the form of a decision table. If a player 
is a batsman and a fielder; or a bowler and a fielder; 
or a wicket-keepers; or a batsman and a bowler; or a 
batsman, bowler and fielder; or a batsman and wicket- 
keeper, he is enrolled into the team. In all other cases, 
he is rejected. 



R1 

R2 

R3 

R4 

R5 

R6 

ELSE 

Batsman 

Y 

- 

P 

Y 

Y 

Y 


Bowler 

F 

Y 

- 

Y 

Y 

- 


Pielder 

Y 

Y 

- 

Y 

P 

- 


'vicket-keeper 

- 

— 

Y 

1 


Y 










Enrolled in 
the team 

■y 

X 

X 

X 

X 

X 


Rejected : 







X 


Pigure 3.2 Example of a Decision Table. 

The procedure just mentioned is shown in the form 
of a limited entry decision table in Pigure 3.2. Since 

4 

there are 4 condition stubs, a maximum of 2 i.e. 16 rules 
is possible. Howeven- since only 6 combinations of the 
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conditions are pertinent to the procedure, the ELSE rule 
specifies that a player is rejected under all other 
conditions. 

3.1.3 SOm REMARKS ON DECISION TABLES 

Decision tables provide a precise, concise and 
(yet) readable description of a procedure. They assist 
completeness of specification by m^ing conspicuous any 
omission in the logical sequence of a problem definition. 
They pinpoint ambiguities in problem specification and 
thus serve as a useful diagnostic aid . They encourage 
modularity by making it possible to divide a complex 
procedure into a set of linked decision tables. They 
serve as a good documentation device. The fact that 
decision tables can be inputted to a computer directly 
makes them an active documentation device rather than a 
passive one like flowcharts. 

Though not an explicit disadvantage, one precaution 
must be observed regarding the usage of decision tables. 
Decision tables have a parallel structure (the order of 
testirg the rules and conditions being immaterial). Hence 
forcing decision tables on a procedure in which the order 
of testing the conditions is important could be awkward. 
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3.2 DJi]GISIOM TABLES K)R SYNTAX RECaGmiOF 

"’’e contend here that decision tables constitute a 
convenient tool for syntax recognition. Any syntax recogni- 
zing process is a multi-decision procedure. For instance 
let us consider a typical BFF production depicting the 
syntax of a BO statement. 


^/Unlabelled B0\^ ^ 
statement 


BO<i[^tateinent Number^- C^nteger 
Variable Fam^ = •|^<^nsigned Intege^ 
<Clnteger Variable IJam^ t , 
|^<C[Unsigned Intege^ | <^nteger 
Variable BameS f I < , J <CUnsigned 

^ j L t I .11 

Integei^ I <ilnteger Variable Name^ ? 

a’ 


Given this syntax, to check whether a source 
language statement is an unlabelled BO, statement or not, 
the procedure to be adopted by a recognizer is shown in the 
form of a flowchart in Figure 3.3* The flowchart has been 
used to avoid the lengthy and cumbersome natural language 
interpretation. It can be seen that a number of conditions 
are to be satisfied and actions taken depending on the 
former's outcome. The same procedure is shown as a set of 
linked decision tables in Figure 3.4. 


The intent of the 10 decision-making boxes in the 
flow chart of Figure 3.3 is displayed by the 6 linked decision 



Seen the 
first two 



( 0 ontlnu ed on next n as e ) 
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Advance Scan 


Table 1 


ELSE 
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(1) 
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(2) 
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ce 

^can 


Go to 


Table 

2 

Tail 

exit ' 




Table 2 




Table 4 


Equal Sign 

Y 

F 

Advance 

Scan 

X 


I = 1 

X 


C-o to 

Table 5 

X 


Fail Exit 


X 


Table 5 

Integer 


Variable 

Nacje 
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— 

N 

u 

Unsigned 

Integer 
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Y 

U 

u 

I >2 


— 

U 

Y 

Advance 

Scan 

X 

X 



Go to 

Table 6 

X 

X 



Error Exit 




X 

Pail Exit 



X 



(Oontinued on next page) 



Table 6 


Comma 

Y 


u 

1 

I>1 

- 

N 

Y 

y 

Blank 

- 

- 

Y 

N 

Advance 

Scan 

' X 




I = 1+1 

X 




Go to 

Table 5 

X 




Success 

Exit 



X 


Bail Exit 


X 



Error Exit 




X 


Pigure 3.4 linked Decision Tables for 
recognizing the Syntax of a 
DO statement. 
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tables of Figure 3.4. It may be seen that the first 4 
decision tables have only one or two conditions. This is 
because they appear in a path which is strictly sequential. 
Unless one condition is satisfied, the next condition need 
not be tested. Ue have not contrived to combine these 4 
tables since it v\rould result in a clumsy and unnatural 
notation. Only when both branches of a decision-making box 
in a flowchart extend at least beyond one level, the 
combination of such boxes into a decision table would be 
meaningful. In constructing decision tables from a 
decision-making procedure which is partly sequential and 
partly parallel, the natural form of the procedure should 
be preserved. Only then can the resulting decision tables 
retain all the advantages of preciseness, conciseness, 
modularity and readability. Added to this is the main 
advantage that these decision tables can be directly fed to 
a computer. 

The advantages of using decision tables for syntax 
recognition are two -fold s a) syntax recognition in compilers 
is a predictive process. It is assumed that a given source 
language statement belor]gs to a certain class of syntactic 
unit. If the source statement does not belong to this class, 
it will be evident during the early stage uf syntactic 
analysis (for most syntactic units). However if the empirical 
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form of the source stat ement ’ does confirm to a particular 
syntactic unit but certain parts of the source statement 
seem out of place, it means that the source statement is - 
syntactically illegal. In such a case, suitable diagnostics 
are to be provided to the user so that he can locate and 
correct the error. By using decision tables for syntax 
recognition, we believe, it is possible to provide excellent 
error diagnostics. In a decision table depicting a given 
syntactic unit, the rules specify the combinations of 
conditions v/hich recognize a legal syntactic unit. One 
could incorporate extra rules specifying some invalid 
combinations of conditions the action part being an error 
exit after printing diagnostics. These extra rules no 
doubt depend on the ingenuity of the programmers and his 
capacity to anticipate possible syntactic errors. Sven if 
one cannot predict all such errors in advance, moie rules 
can be added after gaining experience with the compiler. 

This is quite simple since decision tables are extremely 
amenable to modification. Sor pathological cases of 
syntactic errors, decision tables may not be able to 
provide suitable diagnostics and in our experience even 
hand -coded compilers fare no better in such cases. 

b) A syntax recognizer using decision tables is efficient 
and it can be evaluated by an objective criterion. This 
is due to the fact that there exist several algorithms to 
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convert decision tables into computer programs for minimal 
storage (MTHU69) or minimal time (G-ANSS) requirements. By 
using a minimal run-time algorithm, the syntax recognizer 
could be made fast (storage not being a stringent restric- 
tion except for in-core compilers). This is no small 
advantage considering the fact that the recognizer is a 
substantial part of a compiler and hence it will be used 
over and over again. 

3-3 PRACTICAL IlLU.dTaA.TIOIT OF THE GOHaEPT 

To illustrate the feasibility of the concept 
suggested by us, we Lave developed a small compiler for 
a limited subset of PORTRAJf IV. Illustration being the 
main motivation, the effort lacks detail and it is not 
expected to present a working language. These limitations 
resulted from the limited time at our disposal. 

Use has been made of the Decision Table to 
BOETEAlf TV translator DELTA available at our Computer 
Centre. Recognition of the syntactic units has been 
completely done with decision tables and auxiliary details 
like scanning and chai’acter recognition have been programmed 
in EORTMN IV . 

fe now present an example of a decision table^^^^ ^ 
which recognizes EOETRAET IV identifiers. This is shown in 
Eigure 3.5* ^<^6 explain here the parameters used in this 
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decision table. N is the number of characters in the 
identifier, which is iniatialized to 0 before entering 
the table. IPIAGI and Il'IAGr2 are flags used by the 
routines checking for alphameric characters and digits 
respectively. These flags are initialized to 2 before 
enteriig the table and are set to 0 if the check fails 
and 1 if it succeeds. TStiP is an array of 6 words in 
which the characters of the identifier are- stored one per 
word as and when they are recognized. G is the current 
position of the scan. The routine NUIfflER checks for 
numbers; SCAN advances the scan every time it is called; 

CHAR checks for alphameric characters; and NIGIT checks 
for digits. With this baci^ccund, the modus operandi of this 
decision table should be self-explanatory. 

In conclusion we contend that decision tables 
comprise an efficient and pragmatic tool for syntax 
recognition and provide a convenient ', form of documentation. 
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CHAPTER IV 


EEGISIOH TABLE AS A TOOL FOR 
expressing SEi^aNTIGS 

4 . 1 GRAVITY OF THE PROBLEM OF SEt'JANTIGS 

Most of the work towards a general programming 
language processor has been centred around the syntax- 
directed approach which borrows heavily from the theory 
of natural languages (also known as linguistics). The 
phrase structure grammar is the backbone of this approach. 

The fallacy of adopting phrase structure grammar as the 
central model has been expounded in (HAI68). While the 
phrase structure grammer has been proved (GHOM63) to 
inadequate model for expressing syntax itself (being unable 
to account for any context-sensitive features of a language), 
its failure to provide for any specification of semantics 
is not suprising'. It is more appropriate to say that it 
was never intended to account for any semantics. A grammar 
is a methodology for generating and/or recognizing syntac- 
tically legal sentences in a language. However advocates 
of the syntax-directed approach have contrived to extend the 
phrase structure grammar ■ somehow to provide for the semantics 
of the programming language being defined. The result is 
an unnatural and cluttered notation which is difficult to 






comprehend and more difficult to append. 


Before we proceed to discuss a less popular hut a 
more pragmatic approach, it is important that we appreciate 
the gravity of the problem of semantics with regard to 
programming languages. Natural languages have a standard 
form and though they are legion, they are not likely to 
multiply themselves in future. Therefore dictionaries have 
solved the problem of semantics for them. In contrast, 
programming languages are evolutionary by nature and they 
have no meaning by themselves. They HAVE to be translated 
into some machine language so that they give rise to 
executable programs. The requirements of computer users 
are so diverse that no sirgle language can hope to meet 
these requirements. Besides, computers are produced by 
different manufacturers in a competitive atmosphere so that 
any possibility of a standard machine language is ruled 
out. Thus neither the source language nor the target 
language is standard. And the problem is to find a 
general scheme of semantics which can interpret a given 
source language in a given onject language I To add to the 
complexity of this already complex problem, new languages 
have come up for picture processing, natural language 
discourse etc. These languages describe activities to 
perform which the computer was not originally designed. 
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(’?e do acknowledge existence of exceptions which are special 
purpose computers like IlLIAO IV (KUCK 68)). So for each 
source statement in such languages, it will require a number 
of lines of machine code to execute it. With this picture 
in mind, we proceed to a discussion of a plausible solution. 

4.2 C ANOdiaAL AGTIOITS kOR SPEOIFYING SElfAITTIGS 

As outlined in 2.3.1, we believe that the answer to 
the problem of semantics lies in the macro-processor 
approach, The intent of a source statement has to be 
executed by a machine. Since machine instructions exist at 
a micro level, it would be too cumbersone and time-consuming 
to interpret a source statement directly at machine language 
level. A good compromise would be tp deocribe the capabilit- 
ies of a machine through a set of canonical actions coded as 
macros. Three distinct advantages v/ould emerge out of such 
an approach - 1 ) It is possible to incorporate run-time 
diagnostics into these macros. For instance, checking for 
overflows and underflows in arithmetic operations and 
checking for v\;ild transfers within the memory can be carried 
out within these macros 2) Any machine dependent code 
optimization can be introduced within the macros. 3) By 
executing all user program instructions under the control 
of these macros, it is possible to implement interpreters. 
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An essential prerequisite is that the set of 
canonical actions should not be a closed one. (Otherwise 
we will be left with the sane inflexibility encountered 
in conventional ccmpilers). The user must have the facility 
to define new actions either by combining the existing 
canonical actions or at the rQachine level itself. This 
would leave scope for the ingenuous user who wants to add 
his own features to an existing language. Possible remedies 
for the deficiencies of the macro-processor approach were 
discussed in 2.3-2 which justifies our having choosen the 
macro-processor approach in principle for specifying 
semantics. 

4.3 RULE OP DECIGIOh TABI H S CT SPEOIIjYING- SEWITTICS 

I'e have now at our disposal a set of actions with 
which we can interpret source language statements. But the 
main question now is as to what actions are to be used under 
what conditions. Por instance in FORTRAN, a TO statement 
has an optional specification of increment. If the incre- 
ment is missing, it is to be taken as 1. This fact is not 
made use of by the syntax recognizer. It is the semantics 
routines which should recognize this fact and take suitable 
action. Thus a distinction is made between the syntax- 
checking and code-generating aspects of a compiler. 



The main advantage accruing out of this clear distinction 
is that execution- time diagnostics for user programs can be 
incorporated within the canonical actions. 

The decision-making to be done by semantics routine 
can be conveniently displayed by decision tables. This 
facilitates (in the form of additional rules) the checking 
of several features which c anno t be checked by a syntax 
recognizer (since they do not come under its purview), Por 
instance, in a DO statement of the form "BO nn ii = d1,d2,d3 
the syntax recognizer does not check v>;hether d2 > d1 or not. 
(If this condition is not met, most PORTRAh compilers 
realize it only after going through the BO loop once). We 
have already discussed in Chapter III, the advantages of 
using decision tables and hence we do not reiterate them 
here. 

4-4 :5UGGESTEB SET OF GAHONIGAl ACTIONS 
a) Arithmetic Operations 

i) ABB A., B, RESULT The values represented by the 

symbolic names A. and B are added 
and the result stored in RESULT 

ii) SUB A, B, RESULT The value represented by the 

symbolic name B is subtracted 
from that represented by A ana 
■the result stored in RESULT 



ii) IJ-TICP A, LABEL 


iii) PJl!? A, LABEL 


iv) ZJJCP A, LABEL 


c) Stack Operations 
i) STAGE NAME 


ii) PITCH A, MB 


iii) POP SAVE, HAIvlE 


specified by LABEL. If this fid.d 
contains a number, it is inter- 
preted as a PORTRAH statement 
numb er 

If the value represented by A is 
negative, transfer is made to the 
statement vi/ith LABEL in its label 
field. Otherwise the next sequen- 
tial instruction is executed 
The interpretation is same as that 
of (ii) except that A should be 
posirive 

The interpretation for this, is 
same as that of (ii) except that 
A. should be zero. 

A- stack is created and is given 
the name specified by HAiffi 
The contents of the first field 
are push down the stack specified 
by NAflE 

The top element of the stack 
specified by NAME is popped out 


from the stack and stored in 
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iv) TOP SAVE, 1IA.ME The top element of the stack 

specified by NAME is stored in 
SAVE. The stack is unchanged. 

d) Scan Operations 

A card containing a source 
statemeQX is read and its contents 
are placed in an array BUEE. All 
blanks in the input statement are 
removed 

This generates a pointer which 
initially points to the first word 
of the array BUEE. Each execution 
of SGAI advances this pointer by 
one position 

All the words in the BUEE area 
up to the one having the pointer 
are copied into the array ADEBS. 

e) Miscellaneous Operations 

i ) ELAG llAME, OU/OEE The word v/ith the symbolic address 

NAME is treated as a Boolean 
variable and it is set to 0 or 1 
depending on whether the second 
field contains OEE or ON respec- 
tively 


i) INPUT 


ii) SGAN 


iii) GOPY ADEES 
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The message defined by MESAGE 
is printed on the system output 
unit 

The contents of A and B are 
compared and if a match is found, 
the flag with the name BOOL is 
turned OIT 

The address represented by A is 
incremented by 1 and stored in B. 

We do not claim that this is the most efficient ox- 
complete set of canonical actions. We would only say that 
this is a representative (or typical) set of actions and we 
did use them to write some decision tables for specifying 
semantics. To obtain a good working set of actions, it 
should be chosen by a group of experienced compiler-writers. 

4 . 5 DESIBABIIITY OB DIREGT TRAFSLATIOB OE DEGISIOH TABLES 
TO OxiDER gPBE 

The small compiler which we have programmed (vide 
2.4) was written in- EOBTRAK TV with embedded decision tables. 
So the actions in these decision tables are, of necessity, 
EOSTEAJJ IV statements. ' This implies that the efficiency of 
the compiler written depends on the efficiency of the 
EOM’MN IV compiler which ultimately converts the source 


ii) PRINT MESAGE 


iii) GOMPAR A, B, BOOL 


iv) UPDATE A, B 
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program into the order code of the machine. To avoide such 
dependency, . we feel it desirable to have a decision table to 
order code translator. In this connection, we should mention 
the algorithms available for converting decision tables to 
computer programs. There are tv>/o main approaches viz., the 
rule mask approach (KING 66) and the tree approach (HEIN 66 ). 

In (fRITHU 69) the relative merits of these approaches have 
been ...discussed and a modified rule mask technique has been 
proposed. This new technique has one salient feature which 
was lacking in earlier ones viz., provision for incorporating 
excellent diagnostics at run-time like detection of ambigui- 
ties. Considering decision -tables as a high level procedure 
oriented language, their use would be very restricted without 
proper diagnostics. Since separate algorithms have been 
presented bfor binary and BCD machines in (MUTHJ69), it is 
possible to program a decision table to order code translator. 
To enhance the use of such a translator for writing syntax 
and semantics decision tables, we suggest that it should have 
two modes of workiig - GENERATE and XEGUTE. The actions 
encountered after a GENB.ilATE command should be copied on to 
a tape. Einally this tape will contain the translation of 
the source program. ' The actions encountered after an 
XBCUTB command should be executed straight away. This gives 
the facility to make sane tests at compile-time. Arbitrary 
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switchirg from: one mode to another should be permissible. 
This, we hope, would constitute a flexible and efficient 
translator writing system. 

4.6 EX-AJfPlE OF A SjMAITIGS lEGISIOiT TABLE 

We present here an example of a decision table using, 
the canonical actions of 4.4 to specify the semantics of an 
arithmetic expression (vide Figure 4.1). The method used for 
conversion has been implemented in our small compiler a 
listing of which can be found in Appendix A.- This method 
may be called a modified Reverse Polish scheme. There are 
two stacks viz., MAIN and WORKIffi- . In a pure reverse Polish 
scheme, the complete arithmetic expression is converted into 
reverse Polish notation and left in the MIN stack. (The 
WORKING stack is used for delaying the pushing of operators 
into the MAIN stack until precedence relationship is 
satisfied). In the present scheme, POLISH is a decision 
table which examines the precedence relationship!.: When an 
operator is pushed into the MA.IN stack (which contains the 
operands), control is handed over to the decision, table 
ARITH. In this table, the top three elements of the MAIN 
stack are popped off (one operator + two operands). Code 
is generated depending on the operator and the result is 
stored in a temporary location. The address of .this 
temporary location is pushed into MAIN and control is 
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handed back to POLISH. The process is terminated by POLISH 
when it /..encounters a blank (i.e. terminal character). POLISH 
examines operands as they are pushed into MAIN and turns on 
one of the two flags INTO or PiHAL according to PORTRAIT 
conventions for variable names. If an expression contains 
both integer and real variable namesj both flags will be on. 
In such a case, A.RITH prints an error message and sets the 
mode to REAL. The function of the table should now be 
self-explanatory. 

In conclusion, we contend that decision tables in 
conjunction with a set of canonical actions provide a 
plausible solution to the problem of semantics. 
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CHAPTER V 


T^ ECHA':TIGAL TBANSLATIOH OF SYHTAX 

5.1 THTRODHOTiaJ 

5.1.1 DESIRABI LITY OE AUTOFATIO TRAFSLATIOF OE SYNTAX 

If the syntax-direeted compiler is to be used by 
nonprofessional programmers for defining new languages, 
the syntax specification of source languages should be 
permitted through standard formalisms as far as possible. 
Varied and complex schemes of specification tend to 
discourage the user from attempting the task of defining 
a new language. Further, modifying the syntax specifi- 
cation to affect changes in the language would also become 
difficult. Since BHE is the most commonly accepted method 
of specifying syntax of programming languages, it would 
appear desirable to mechanize the translation of BFP into 
a suitable internal machine representation. Early (EARL 6^ 
has done some work in this direction, aetails of which are 
not available. 

5 .,1.2 DRAf?3ACKS OE DIRECT TRAHSLATIOF 6E 3FE 

We feel that it is not advisable to translate 
directly from BFE for the following reasons : * 

a) BHE has no provision to accommodate the context- 
sensitive features of pfc%ra^ing languages. (This has 
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been discaseed in detail elsewhere (DOIT67) and hence it is 
not repeated here). It turns out that most programming 
languages do have context-sensitive features in their 
syntax and various methods have been adopted to circumvent 
this problem (eg. the explanations given under the caption 
"semantics” in the ALGOL 60 report). Viewed in this sense, 
BVP is not a "ccraplete" scheme of syntax specification and 
hence its direct translation would only be a partial 
solution to the problem of specifying syntax. 

b) If BKI is retained as such for specifying syntax, it 
will not be possible to incorporate appropriate diagnostics 
for syntactically erroneous souioe statements. The syntax- 
directed compiler can never hope to competes with the 
conventional hand-coded compiler, unless it provides 
reasonable diagnostics. It would not be apiJropriate to 
expect the user to submit error-free source programs all 
the time . We feel that this point has not received much 
attention in the literature. 

c) Cantor (0A.1TT62) has proved that there exists no 
algorithm which can decide whether a given Backus system 
(i.e. a set of productions in BNF) is ambiguous, or not. 

inx ' K * ■ ■ ■■ ■ 

So even if BFP were to be directly translated, the ambigui- 
ties in the given "syntax specification would remain 
undetected. Thus compiler itself will hot be free of 



"bugs” . 
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d) Fo algorithms, to our knowledge, have been reported in 
the literature for the automatic translation of BFE. Since 
the efficiency of the recognizer would depend directly on 
the outcome of this translation, this would take us farther 
from the elusive common efficiency criterion for syntax- 
directed compilers. 

5 . 1.5 USE 0? AF IFTERFEDIATE LEVEL IF TaA.FSlATIFG BFg 

In view of the arguments presented in 5-1.2, it 
is clear that the automatic translation of a BFP specifica- 
tion of syntax does not result in a complete recognizer. 

As an alternative, one could translate BFB into an 
intermediate form, the- latter being chosen in such a way 
that it can overcome the deficiencies mentioned in the 
earlier section. Obviously this phase of translation 
(where "translation” is not used in a strict sense since 
the process involves translation + inclusion of certain 
features like context sensitivity) requires human attention. , 
The price paid in this does not seem too heavy in the light 
of the inadequacies of a direct translation. The translation 
from this intermediate form into machine representation can 
certainly be autoraated. 

state graph, used to represent finite state 
Theory seems to be a useful inter- 
use -of the state graphs 
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for syntax specification can be found in (G0EW61) and 
(GON63) which are discussed in subs eq,uent sections. We 
call the state graph specification as an intermediate 
form, since syntax specification has to necessarily 
originate at a natural level like BlTp. The problem of , 
conversion from this intermediate form will be discussed 
in 5.3 . 

5.2 SKBljim WORK OK STATE GRAPH APPROACH TO MGUA&E 
DE SCRIPT I OH 

5.2.1 GOHWAY’S SEPARABLE T.MHSITIOI DIAGRAM OQMPIIER 


Conway (COH63) gives an account of a separable 
transition diagram compiler for GOBOI. The scheme 
suggested by him is essentially centred around the state 
graph approach to the description of programming languages. 
The main virtue he claims for his compiler is its 
"separability". Dependirg, on the storage capacity of a 
given computer, the compiler can be broken into a number 
of segments under the restrictions that a segment leaving 
the high speed core storage is irrevocable and that two 
working tapes are required. The first restriction is 
concerned with the modus operandi of the compiler and its 
feasibility is proved informally by the author with the aid 
of the "coroutine" concept. The second restriction can be 

^■•.#03.% IdOaiputer inst allations. 


easily met 
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Conway’s compiler can be broadly divided into 
three phases - 1) Lexical Analysis 2) Syntactical Analysis 
and 3) Code Generation. During Lexical analysis, all the 
metavariables in the source text (eg. class identifiers in 
ALGOL) are reduced to single character codes. low the 
modified input string is fed to a "diagrammer" which has 
a "window" to hold the source (or modified source) symbol. 
This serves as the input symbol for the starting state of 
the transition diagram (or state graph) being traversed 
currently. (Sach syntactic type has a unique transition 
diagram which may also refer to other syntactic types). 

Thus the diagrammer acts as a top-down analyzer. The output 
of the diagrammer is an intermediate code (Suffix Polish in 
the author’s example), it this point the code generator 
takes over and produces the object program. 


The transition diagrams used in syntactical 
analysis ace in essence jborr owed frora Automata Theory. The 
only difference is that an ’laction" is associated with 
every transition from one state to another.. The author 
mentions two conditions on the transition diagrams which 
we intend to discuss in d^etail. The first one is the 

oop condition" which says that no transition diagram 
l-X feipke ^ , ref eren ce to itself without having ' first read 

> it was entered. This ensures the 


an input'''*^"'^"*' ' 

- 



prevention of endless loops. The second one called the 
"No-Backup condition" defines away any need to specify an 
orher in which the nonblank paths leading from a node are 
to be traversed. When a path has a syntactic type on it, 
an input symbol is called an initial input symbol if and 
only if it is in the input window arh when the . transition 
diagram defining the syntactic type on the path in question 
is entered, that symbol will be read before either a dead 
end occurs or the diagram is exited. Thus the No-Backup 
condition implies the No-lpop condition and further states 
that for every node in the system of transition diagrams, 
the sets of initial input symbols of all the paths leading 
from that node are disjoint. The author cites three 
distinct advantages of the No-Backup condition viz., 

1) No backing up of the input string during scanning is 
neoaeeery when a parse fails. 2) Specific diagnostics can 
be provided for syntactically erroneous source texts and 
3) The ambiguity problem (GANT62) is legislated out of 
existence in languages defined by transition diagrams. 

The first and the third advantages would be ideal 
for any compiler and (may be hence) certainly do not accrue 
together from the author's scheme. Bor instance when two 
syntactic units have one or more common units in the same 
order in an altermtive, going monotonically along one path 
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may leave one at a dead end. The author suggests a multiple- 
exit transition diagram wherein different syntactic types 
with the coiamon feature mentioned above result in different 
exists. When this type of modified transition diagram is 
used, there is no guarantee that the actions associated with 
several syntactic types are very different which means that 
the third advantage is lost. Thus the logical "Exclusive 
OR" of the first and third advantages can be considered the 
resultant advantage. Though the author is not totally 
unaware of these drawbacks, he would have done well to 
claim these advantages in a limited sense. 

The author mentions at the outset that his scheme 
is a rebuttal to the belief that syntax-directed compilers 
are inefficient with regard to storage requirement and 
speed of translation. One of the main advantages claimed 
for syntax-directed compilers is the relative ease with 
which one could modify the source language. It is 
surprising that the author does not even mention schemes 
for making modifications to his separable transition 
diagram compiler. 



Gorn (GORMbl )' has summarized the well known 
specifi cation, li^^l^es for mechanical languages and their 
processors. Most of the specification languages are only 



of theoretical interest since no significant attempt has 
been made to implement them on a conpater. The notable 
exceptions are BUP and flow charts (the latter serving 
only as a documentation device rather than for machine 
implementation) which have gained popularity. G-orn's 
presentation is graphic and inforaative and we have nothing 
to add to it. Our interest is to borrow his concept of 
"Incidence Matrix" which will be used in. 5.3.1 with some 
modifications. Gorn's idea was to develop the path and 
connectivity matrices from the (two) symbol - transition - 
state matrices (or incidence matrices). So he suggested a 
two-stage process in which the state graph is first 
converted into a symbol-state graph (a set of two directed 
graphs) and then developing from it the symbol-transition- 
state matrices. We have changed this into a one stage 
■process by altering the structure of the incidence matrix. 
Our motivatioii, no doubt, was machine implementation. In 
the modified form of the incidence matrix, each column has 
a name representing a transition of the form XXX/lTY. The 
rows represent the states of the state graph. Retaining 
Gorn’s notation for making entries in the incidence matrix, 
the process of developing the incidence matrix from the 
state graph is quite simple as ?d.ll be shown in the next 
section. 



5.3.1 PRi.GMTIOS OF ’UlUJSSMTIllQ STATE GRAPHS Ii'TO M/OHINE 
REPilllSEIJ NATION 

Having decided upon the state graph as an inter- 
mediate form of syntax representation, the immediate problem 
is its conversion into internal machine representation. It 
must denoted here that the result of translation of a state 
graph will be a part of a compiler which will be used for 
compiling many a source program. So the importance of the 
efficiency of the translated state graph (i.e. in effect 
the compiler) cannot be overemphasized. Since no rigorous 
algorithms to convert state graphs to computer programs 
have been published hitherto (to the best of our knowledge), 
the efficiency of such a conversion cannot be determined. 

It is advisable to convert state graphs into a suitable form 
for whose machine translation rigorous algorithms exist. ¥e 
choose decision tables as the second intermediate form for 
the following reasons. The similarity between decision 
tables and finite state machines has been proved in 
(OTTHU69). Hence the translation from a state graph into 
a decision table is a natural rather than a contrived 
process. Secondly.,, there exist proven algorithms for 
converting decision tables into computer programs (eg. 
(mTHUeg ) ) . Eventhough the translation of syntax from BEE , 
to machine-usable form seems to be a multistage process, 
it has to' through only ONCE for a given source 
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Whenever there is a / after such symbol, the entry therein 
indicates the action to be taken. 

c ) Incidence Matrix for the above State graph 

The transitions in the state graph are denoted by 
T(1), T(2) ... etc. The incidence matrix is developed by 
entering a -1 for an arrow (i.e. transition) leaving a state, 

+ 1 for an arrow entering it and +1 for an arrow leaving and 
entering the same state. When a transition is not pertinent 
to a given state, a 0 entry is made. The incidence matrix for 
the state graph in Figure 5.1 is shown in Figure 5.2. 


Transition 


State\T(1) 

C\J 

T(4) T(5) 

T(6) 

T(7) 

00 

T(9) 

T(10) 

T(11 ■ 

SI 

-1 

■ 0 

0 

- 0 

• O' 

•0 

0 

0 

0 i 

i 

■ 0 : 

0 

S2 

+1 

-1 

0 

0 

: 

0 ; 

0 

^■1 

0 

+1 

-1 

0 i 

S5 

1 

0 

+1 , ■ . , 

-1 

+1 

0 

0 

0 

0 

0 

0 ■ 

-1 

S4 

0 

0 

+1 

-1 


-1 

0 ■ 

0 

0 

0 

0 ; 

S5 

0 

0 

0 

0 

r ■ 

+1 

0 

1 

0 

-1 

-1 

+1 

\ 

° i 

S6 

0 

0 

0 

0 

0 

+1 

+1 

+1 

: 0 

0 

1 

f 

+1 i 


Figure 5.2 Incidence Matrix for the State 
Graph in Figure 5.1- 
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T Array : 


T(1 ) 

; Y 

T(2) ; 

+ T(3) 

; Y 

T(4) : 

+/R1 

T(5) 

s * 

T(6) ; 

V T(7) 

t Y 

T(8) : 

0 

T(9) 

; Y/S2 

T(10) ; 

* T(11) 

; 0 



d) 0 

onversion 

from Incidence Matrix to 

Decision 

Table 



In the incidence matrix, each element of the 
T array will be of the form XXVtYY where /lYY is optional. 
The format of the decision table to be generated is shown 
in Figure 5.3 infoimally. 


Present State 

i 

Present Symbol 

XXX 

Present State =' 

k 

Reduction ^ 

R1 or R2 

Exit ^ 

B or ]6 


Figure 5*3 Format of the decision table 
to be generated. 

Let the nuraber of states be m and the number of 
transitions n. Then the incidence matrix will be m X n 
in size. Let c (which will be used for referring to the 
columns of the incidence matrix) be initialized to 1 . 

Step I 

In the column, if the i'^h row contains -1 and 

the k'th row contains +1, make i as the condition entry 
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against the condition stub "Present State" and k as the 
action entry against the action stub "Present State = ". 

If k is equal j to 3 , where 3 is the number of the error 
state (6 in this example), put a marker "E" as the action 
entry against the action stub "Exit". 

Step II 

Por the column number c of the incidence matrix 
access tne c'th elemoat of the T array. 

Step III 

Prom the T array element (of the form XXX/YYY) 
tai e XXX and make it the condition entry against the 
condition stub "Present Symbol". If YYY is present, then 
make it the action entry against the action stub "Reduction". 

Step IV 

One rule of the decision table has been created. 
Increment c by 1 and if c<n go to Step I. Otherwise halt. 
(The procedure is repeated for all the n columns of the 
incl( ence matrix) . 

Applying the above procedure for the incidence 
matrix in (c) the decision table in Eigure 5.4 is obtained. 
Por the sake of brevity, we have omitted details like 
reentering the table, movirg the scan etc. whiuh would be 
valid action entries for all rules without error exits. 



The decision tables generated thus can be fed to a pre- 
processor (using any of the algorithm's in (BroTHUbg) or 
(GANSS)) which would convert them into the order code of 
the computer. 



Figure 5.4 Decision table generated by 
the algorithm in (d ) . 

5 . 3.3 ITiPlEMBMTATION OF THE ABOYE A1GOEITB-! FOR BINARY 
MAGHI^TBS 

''^^e present here a scheme for implementing the 
algorithm of 5.3.2 on binary machines. The entries in the 
incidence matrix viz., 0, -1, +1 and +1 are coded as 0, 

1 , 2 and 4 respectively. (The internal representation in 
the machine would be 000,001,010 and 100). show an 
example of an incidence matrix with the above coding in 
Figure 5 . 5 . 
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1 0 0 1 2 

0 0 2 0 0 

2 0 0 2 1 

0 10 0 0 
o 0 1 0 0 

0 2 0 0 0 

Figure 5.5. Example of a coded 
Incidence Matrix, 

The coded incidence matrix should be fed columnwise 
to the computer. The problem is to find the state from which 
the transition originates and the state on which it terminates 
in each column (i.e. for a given transition). This can be 
done as follows. Consider the machine representation of a 
given column shown below : 

00100001000)000000 (Column 1 of Figure 5.5) 

This should be ANDed logically with 

001 O01 001 001 001 001 . 

The result would be 001000000000000000. By finding the 
position of the 1 bit in this number (which can be 
accomplished by shlftiaag the bits until a 1 is found and at 
the same time keeping, track of the number of shifts) and 
dividirg it by we obtain the number of the state from 
which the transition originates,, ■ ... 



Similarly by AKDing the column logically with 
01 001 001 001001001 0, locating the position of 1 in the ' 
resulting nuniber and dividing it by 3, we can obtain the 
nunber of the state on which ■' the transition terminates. 

■ - 4 , " " . ■ 

In the event that a given transition originates and termi- 
nates on iiie same state, there would be only one entry 
(viz., 100) in the corresponding column of the incidence 
matrix. This possibility (which arises only if the earlie 
two have failed) can be detected by ANling the column 
logically with 100100100100100100 and dividing by 3 the 
position of T in the resulting number. Since a byte in a 
binary n® chine can accommodate two octal digits, the 
columns of the incidence matrix can be conveniently packed 
into single machine words. 
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MD SIJGGE5TI0IS FOE FURTHER RB, SEARCH 

The syntax-directed approach towards a general 
programniing language processor has concentrated mostly on 
the formalization of syntax leaving the problem of seman- 
tics in the background . Little has been said about the 
efficiency of translation of the syntax and the semantics 
of prograroining languages. In this th(^is, we have shown 
that decision tables constitute a convenient tool for 
expressing syntax. Modification of the existing syntax 
of B programming language and incorporation of error 
diagnostics is simplified by using decision tables. 


As outlined in (PELDbS), a syntax-directed 
approach, is appropriate only when the 'form' of the 
input to a program contains a significant portion of the 
'content'. This limitation is overcome in the macro- 
processor approach which offers a powerful tool for 
describing the ’content' in terms of actions that a 
Rif-chine is capable of performing. We have used this • 
feature in conjunction with decision tables to express 
the semantics of programming languages. The choice of 
optimal storage or optimal , run-time for programs generated 
from decision tables if ant advantage. 
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The main limitation on the usage of decision 
tables arises when the procedure to be displayed has 
sequential tests of conditions# Decision tables have a 
parallel structure. Hence any attempt to display a • 
sequential procedure through decision tables is bound to 
be artificial and clumsy, crippling the main advantages 
of using them. Thus it is advisable to embed decision 
tables in a computer languj^e which can take care of the 
sequential parts of a procedure. 

As explained in Chapter V, direct translation of 
BNP does not appear to be a useful proposition. Though 
its conversion to state graph form calls for human inter- 
vention, the prospect of efficient translation compensates 
this to some extent. Since the incidence matrix is coded 
in binary form and decision tables are internally coded as 
binary vectors during translation, the possibility of a 
one-to-one translation could be explored. 

Symbol manipulating languages provide a, real 
touchstone for testing any general programming language 
processor. Hence it would be^ worthwhile to test the 
approach suggested by us by implementing a symbol manipu- 
lating language like SNOBQL. We could not attempt this in 
in the limited time.'.at , 


76 


Object code optimization is regaining prominence. 

It would be int er e st ing to try decision tables for displaying 
under what conditions code optimization could be carried out. 
Since this is bound to cost in time, it may be incorporated 
as an optional postsemantic optimizer. 
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/IDFTC 

5 

15 

10 

/IBFTC 

5 

lO 

/IBFTC 

IR 

10 

15 


listing of the littletran compiler 


input noprnt 
SUBROUTINE INPUT 
data BLAN/6H 
BLANK=BLAN 


rnMMnw'^/rnMK, rr »PREV,CURENT, BLANK 

INDEX, blank 

FORMAT{72a1 ) 


K = 7 


DO 15 1=1,72 
IF(IoLTo7)GO to 15 
I F ( WORD ( I ) aEQo BLANK ) GO TO 15 
WORD( K)=WORD ( I ) 

K = K + 1 


CONTINUE 

WORD(K)=BLANK 

PRINT 10,(WORD{I),I=1,K) 

FORMAT(10X,72a1) 

INDEX=7 

RETURN 

end 

scan NOPRNT 
SUBROUTINE SCAN 

INTEGER WORD(72) jPREVjCURENT, BLANK 

COMMON /CONNIE/ WORD »PREV , CURENT , I NDEX s BLANK 
IF( INDEXoEQol )GO TO 10 
PREV=WORD( INOEX-I ) 

CURENT=W0RD( INDEX) 

INDEX=INDEX+1 
RETURN 
PREV=BLANK 
CO TO 5 
END 

CHAR NOPRNT 

SUBROUTINE CHAR 

INTEGER WORD(72 ) sPREVjCURENT, BLANK 

COMMON /CONNIE/ WORD s PREV » CURENT , I NDEX , BLANK 
COMMON /JOSIE/ IFLAGl.lFLAG2r£FLAG3,IFLAGA 
INTEGER CKl»CK2,CK3,CKA,CK5,ck6 

data CK1,CK2 ,CK3,CK4,GK5,CK6/GH0 A,6Ho I,6H0 
,6H0 S,6H0 Z/ 

KTEMP=CURENT 
KZERO = 0 . ' 

FOR M A T ( A 1 » 4X > r*-'L : -■ .^,1; ; 

READl99,l5)CirR^'r ^ ' 

FORMA T(A6) 

IFLAG1=0 
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appendix a 


LISTING OF THE LITTLETRAN COMPILER 


/IBFTC INPUT NOPRNT 

SUBROUTINE INPUT 
DATA BLAN/6H / 

BLANK=BLAN 

integer W0RD(72) ,PREV .CURENT , BLANK 

COMMON /CONNIE/ WORD » PREV , CURENT , I NDEX 5 BlAN K 

READ 5 , (WORD( 1)51=1,72) 

5 F0RMAT{72A1) 

K = 7 

DO 15 1=1,72 

IF{ I oLTo7)GO TO 15 

IF( W0RD( I ) oEQoBLANK)GO TO 15 

W0RD(K)=W0RD( I ) 

K = K + 1 

15 CONTINUE 

WORD! K)=BLANK 

PRINT 10» (W0RD{ I ) » I=1,K) 

10 FORMAT(10X572a1) 

INDEX=7 

RETURN 

END 

/IBFTC SCAN NOPRNT 

SUBROUTINE SCAN 

INTEGER W0RD(72) jPREVsCURENT, BLANK 

COMMON /CONNIE/ WORD ,PREV , CURENT , I NDEX , BLANK 
IF{ INDEXoEQal )G0 TO 10 
PREV=WORD( index-1 ) 

5 CURENT=WORD( INDEX) 

INDEX=INDEX+1 

RETURN 

10 PREV=BLANK 

GO TO 5 
END 

/IBFTC CHAR NOPRNT 

SUBROUTINE CHAR 

INTEGER WORD(72) 5PREV5CURENT5BLANK 

COMMON /CONNIE/ WORD » PREV , CURENT , I NDEX , BLANK 
COMMON /JOSIE/ IFlAG1,IFLAG2,IFLAG3,IFLAGA 
INTEGER CK1»CK2,CK3,CKA,CK55CK6 

data CKl ,CK2 ,CK3 ,CKA,CK5 ,CK6/6H0 A,6H0 I,6H0 

S»6H0 Z/ 
ktemp=curent 
KZERO =0 

WRITE( 99,10) KZERO,GURENT 
10 F0RMAT(A1»AX,A1} 

READ( 99,15 )CURENT 
15 FORMAT! A6) 

IFLAG1=0 


J,6H0 



I flag 2 


N 


tchar 


CALL NUMBER 

oNo 

N=N + 1 

X 0 

TEMP(N)=C 

)& N 0 

CALL SCAN 

0 X 0 

IFLAG2=2 

0 N 0 

CALL CHAR 

«X« 

CALL DIGIT 

0 X 0 

ICHAR 

© H 0 

print 15 

© X «> 

IFLAC3 = 1 

.N© 

GO TO 10 

0 X 0 

RETURN 

ON 0 

N 

0 G T qS 

iflagi 

0 E Q 0 0 ' 

IFLA62 

©EQ0O 

N 


ICHAR 


CALL NUMBER 

0 NO 

N = N + 1 

0 © 

TEMP(N)=C 

©N© 

call scan 

©N© 

IFLAG2=2 

© H © 

CALL CHAR 

© H 0 

CALL DIGIT 

© Ni ' 0 

ICHAR 

©No 

PRINT 15 

©No 

IFLAG3=1 

0 X 0 

GO TO 10 

©No 

RETURN 

©No 

*TLEND 


15 FORMAT! 

IF(N 

0 G T 06 ) 


,EQol 


j EQ o 0 
>GEol 


>EQ = i 


o EQ o Q 


No 

Xo 

No 

X. 

.No 
.Xo 
s X o 
,No 
oXo 

oNo 
oXo 
oNo 
o G T o 6 
oEQol 


oNo 
oNo 
o N o 

o N o 
oNo 

o N o 

o N o 
oNo 
oNo 
oXo 
o N o 
oNo 

o gt 


3 X O 
0 N o 

o N o 

oNo 

o N o 
o N o 
o N o 
o N o 
oNo 
oNo 
u N o 

O X 0 


cNo 
o N o 
o N o 
O N 0 

oNo 
o N o 
oNo 
oNc 
oNo 
o N o 

O N o 

oXo 


.EQ 


,6 

,1 


>No 

„N„ 

oNo 
oXo 
oNo 
oXo 
o X o 
o N o 
oNo 
o N o 
o X o 
oNo 


No 

No 

No 

Xo 

,No 

,Xo 
> X o 
3 N O 


No 

No 

Xo 

No 


Character 


20 

25 

30 


FORMAT ( 6 X) t i m 

WRITE{99,25) (TEMP(I)»I=1’N 

FORMAT (6A1 ) 

READ(99»30)VNAME 

F0RMAT(A6) 

RETURN 

F.ND 


/IdFTC ARITH 

SUBROUTINE ''RI™^^oRD<721 .PREV , CURENT .BLANK 


INTEGER 

INTEGER VNAME dof\/ n irFNT » I NDEX ? BLANK 

k k ■ A jf \ i M A K A CT 


LUNMUIN /viuoAu./ ■ 

COMMON /SHEELA/VNAME .. 3 ,dvD ,PErI0D,EXP0 
integer RTPar,eqsi6n.plus,dvd ^ 

OATA LFPAR.RTPAR.ea^6N.PLUS,MIN 


1 

2 




6H( 

' y,,a: / 

data ,NEG/ 6 H$ ' 

TMxirrcD aqTGN 


Expo/ 

? 6 H/ 


I NT EG £R ; #|f i 
WTaO ¥0-^fUX 
ifi I 






13 


' '/ ' ’’ ^ ^ "a/’'?,-, ' 


'■ap-,"' 
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CALL SCAN 
CALL IDFIER 
10 CONTINUE 

stable table for checking for assignment statement 

-:^^THEAD 

SXDT02 NC = 02 s,NR = Ol ,NA = Ol sRDEBUGsSTACOL 

IFLAG3 oEQol 

CURENT oEQoEQSIGN 

ASIGN=VNAME oXo 

*ELSE 

tflaga=o 

INDEX=7 

return 

^!-TLEND 

13 CALL LIST(MAIN) 

call LIST(WORKIN) 

:.5 IFLAG3 = 2 

17 CONTINUE 

*TAB| E table for ISOLATING OPERANDS IN ARITHMETIC EXPRESSIONS 

*THEmD 


SXDT03 

NC=02,NR=05 

,NA=06,RDEBUG 

,STAC0L 



iflags 

oEQo2 

o E Q o 1 

oEOoO 

o EQ o 0 

o EQo 1 

curEnt 


oNEoBLANK 

oEOoBLANK 

oNEo blank 

o E Q o Blank 

CALL SCAN 

cXo 

o N o 

o N c 

o N o 

o N o 

CALL IDFIER 

oXo 

oNc 

o N o 

o N o 

o N o 

CALL NEWTOP 

o N o 

(VnAmEsMAIN ) 

O M c 

0 N O 

( VNAME sMAI 

GO TO 18 

o N o 

o X o 

o N o 

o X o 

o N o 

GO TO 30 

oNc 

oNo 

o X o 

o N o 

o X o 

GO TO 17 

*tlend 

oXo 

c N o 

oNo 

o N o 

oNo 


18 IF ( IFLAG3„EQoO )G 0 TO 2o 
KZER0=0 

WR ITE ( 99,1 )KZER0»VNAME 

1 F0RMAT(A1,4X,A1 ) 

READ(99,2)M0DE 

2 F0RMAT(A6) 

INTEGER CK22 

DATA CK22/6H0 N/ 

INTEGER CKl ,CK2 ,CK3 ,CK4,CK5 ,CK6 

data CKl ,CK2 ,CK3 ,CKA9CK5 ,CK6/6H0 A,6H0 I ,6H0 J,6H0 

1R,6H0 S,SH0 Z/ 

IF(MODEoGEoCK2oANDoMODE<,LEoCK22)GO TO 19 

IREAL=1 

GO TO 20 

19 INTG=1 

20 CONTINUE 

stable table FOR CONVERTING FROM INFIX TO SUFFIX POLISH 
*TEXPR 

LOGICAL BOOL1,BOOL2,BOOL3,BOOLA,BOOL5,BOOL6 

INTEGER CjTOPS 
B00L1=oFALSEo 
B00L2=„FALSEo 
BOOL3 = <,FALSEo 

BOOLA=oFALSE. 

BOGL5=„FALSEo 
B00L6=^ FALSE = 



NC-10»NR=18 ,NA=08,RDEBUG,STACOL 


MTY=LISTMT{WORKiN) 

TOPS=INTGER(TOP{WORKlN) ) 

KFLAG=1 

C=CURENT 

IF(TOPSoEQoMPYoORoTOPSoEQoDVD)BOOL1 = oTRUEc. 
if(CoEqoPlus=>oRoCoEQominus) Bool 2= o true o 
IF{CoEQoMPYoORoCoEQ<.DVD)BOOL3=oTPUEo 

I F ( TOPSoEQo PLUSoORoTOPSoEQoMU'US ) B00L4=oTRUE 
IF(Co EQoEXPOoAnDoToPSoEQoEXPO )B00L5=oTRUE=, 
IF(PREVoNEoEQSlGN) B00L6 = oTRUE . 

*THEAD 
SXDT04 

MTY oEQoO 

CUrEnT oNEoRTPAR 

,PREV 
BOOLl 
B00L2 
TOPS 
BOOL? 

BOOLA 
BOOLS 

BOOL6 ,Yo 

CALL NEWTOP (C,W0RKIN) (C,WORKIN) oN, 

oNo oNo oNi 

oNo oNo oNi 

oNo oNo oN, 

O N o 0 N o 

o X o o X o 

o N o o N o 

o N o o N o 


.NEoO 

oNEoRTPAR 

oNEoLFPAR 


.EQoLFPAR 


EQoMINUS 

^ECoEQSIGN 


CALL NEWtOP 
CALL POPTOP 
PRINT 25 
CURENT=NEG 
GO TO 15 
GO TO 20 
GO TO AO 
MTY 

curent 

PREV 

BOOLl 

BOOL2 

TOPS 

BOOL3 

BOOL A 

B00L5 

B00L6 

CALL NEWTOP 
CALL NEWTOP 
CALL POPTOP 
PRINT 25 

curent=neg 

GO To 15 
GO TO 2o 
GO TO Ao 
MTY 

curent 

PREV 
BOOLl 
B00L2 
TOPS 
BOOL3 
BOOLA 
B00L5 
OOOLf 


,Xo 

,No 

lX O 

,No 

■ NFoO 

-EQoRTPAR 


,Yo 

,EQoNEG 


cNo 

(TOPSjMAIN) 

(WORKIN) 

oNo 

o N o 
oNo 
oNo 

oXo • , , 

oEQoLFPAR 


oEQoEXPO 

oYo 


oN, 

(TOPSsMAIN) 

(WORKIN) 

»No 

oNo 

«No 

..o X , 


.NFoLFPAR 


.EQoNEG 






.Y,o 

,EQ. 


EXPO 






oEQc MINUS 
o EQoLFPAR 


.No 
■ No 
,No 
,No 
.Xo 

,No 
> X O 
,No 

.NE. 

>EQ. 


0 

RTPAR 


, EQoLFPAR 


0 N o 

{ TOPS, MAIN) 
(WORKIN) 

o N o 

o N o 
.No 
oNo 
o X o 


.No 
0 N o 

(WORKIN) 

cNo 

oNo 

oXo 

oNo 

oNo 

oEQ.NEG 
o Y o 
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CALL NEWTOP 

(C , WORKIN ) 

O N O 

o N o 

o N o 

o N o 

call NEWTOP 

O N C> 

(TOPS, MAIN) 

( T0PS,MAIN ) 

( TOPS^MAIN ) 

{TOPS 5 MA 

CALL POPTOP 

'cNo 

(WORKIN) 

( WCRKIN ) 

(WORKIN ) 

( WORKIN ) 

PRINT 25 

o N o 

o N o 

o N o 

o N o 

0 N 0 

CURENT=NE 6 

o N o 

O N 0 

o N o 

o N o 

0 N 0 

GOTO 15 

oXo 

oNo 

oNc 

o N o 

0 N 0 

GO TO 20 

o N o 

oNo 

o N o 

oNo 

0 N 0 

GO Tu Ao 

oNo 

cXo 

o Xo 

C X O 

0X0 

MTY 






curent 



oEOoNEG 



PREV 






BOOLl 






BOOL2 

oYc 





TOPS 



cEOoNEG 



B00L3 






BOOLA 

cYo 





BOOLS 


oYo 




B00L6 






CALL NEWTOP 

O N o 

o N o 

oNc 



CALL NEWTOP 

( TOPS, MAIN ) 

(TOPS, MAIN) 

( TOPS , MAIN ) 



CALL POPTOP 

(WORKIN) 

(WORKIN) 

(WORKIN) 



PRINT 25 

cN„ 

oNo 

oN. 



CURENT=NEG 

O N o 

cNa 

o N o 



GO TO 15 

oNo 

CJ N o 

o N o 



GO TO 2o 

oNo 

oNo 

oNo 



GO TO AO 

„Xo 

0 X 0 

oXo 




^ELSE 

CALL NEWTOPICsWORKIN) 

GO TO 15 

*TLEND 

25 FORMAT ( IX, terror- ONE OR MORE UNBALANCED PARENTHESES*) 

30 IF(LISTMT(W0RKIN) cNEoOGO TO 35 

NRES=INTGER(P0PT0P(MAIN) ) 

FRINT 51,NRES 
IF( IFLAG5oEQo1 )RETURN 
PRINT 60, ASIGN 
RETURN 

35 1F( INTGER(T0P(W0RKIN) ) o-.'QoLFPARlGO TO 37 

CALL NEWTOP (TOP(WORKIN) ,MAIM) 

CALL POPTOP (WORKIN) 

KFLAG=2 
GO TO AO 

37 PRINT 25 

CALL POPTOP (WORK IN) 

GO TO 30 

AO CONTINUE • 

KSYMB=INTGER(P0PT0P(MAIN) ) 

IF(KSYMBoEQ<.NEG)GO to A98 
I ADR2=INTGER( POPTOP ( MAIN ) ) 

IADR1=INTGER(P0PT0P(MAIN) ) 

G^ 

A98 I ADr2=INTGER ( TOP < main ) ) 

DATA KT/AHTMP+/ 

7A FORMATdX.rcERROR- MIXED MODE IN ARITHMETIC EXPRESSION*) 

80 FORMAT (AA, l2 ) 

75 FORMAT (AA, I 1»1X) 

85 F0RMAT(A6) 

INTEGER TMP 

AA IF(NToGTc.9)G0 00 A5 



WR.rTE(99975 )KT»i 
read ( 99, 85) IMP 
GO TO 47 
WRITE(99,80) KT 
READ(99,85)TMP 
IF( INTGoNEol, 
IREAL =0 
PRINT 74 
CONTINUE 

-E table for 


ORo IREALiNEo 1 )GO TO 5o 


50 CONT 

^(■TABlE 

*THEAD 

GMD TO 1 

INTGoEQol 

IREAL cEQo 1 

ksymb 

PRINT 51, 
PRINT 52, 
PRINT 62, 
PRINT 53, 
PRINT 63, 
PRINT 54, 
PRINT 55, 
PRINT 65, 
PRINT 56 
PRINT 54, 
PRINT 57, 
PRINT 67, 
PRINT 58, 
PRINT 54, 
PRINT 55, 
PRINT 65, 
PRINT 66 
PRINT 59 
PRINT 6 o, 
PRINT 7o, 


generating order CODE FROM ARITHMETIC 


express I 


NC=03 ,NR= 
oYo 


11 ,NA=20,RDEBUG,STACOL 

o Y o 


oEQoPLUS 
lADRl 
lADRZ 
O N o 
oNo 


0 Y o 

oEQoPLUS 

1 ADRl 
o N o 
IADR2 
oNe 


c EOoMINUS 
I ADRl 
0 N o 

0 N o 

1 ADR2 
o N o 


oYo 

“EQoMINUS 
lADRl 
o N o 

oN, 

,No 

IADR2 
o N o 
o N o 
oNo 

cNo 
o N o 
o N o 
o N o 

oNc 


oEQoMPY 
Q N O 
o N o 
,N» 

= Na 

0 N o 

1 ADRl 
IADR2 
o N o 
oN = 

0 N o 

oNo 
o N o 

eN, 

o N o 
cNo 
o N o 
oNo 

oN« 

oNo 

TMP 





0 Y G 


gYg 




0 Y o 


oYo 


O Y 0 



oEQoMPY 

G E Q 0 D V D 

o Eo o D V D 

oEQgEXPO 

o EQ o E 

PRINT 

51, 

oNo 

gNo 

o N o 

0 N o 

oN 0 

PRINT 

52, 

,No 

oNg 

o N o 

gNg 

oNo 

PRINT 

62 , 

oNo 

O N 0 

o N « 

o N o 

o o 

PRINT 

53, 

oHo 

gNo 

o N o 

o N o 

0 N 5 

PRINT 

63, 

oNo. 

gNg 

gNg 

G N O 

0 N 0 

PRINT 

54, 

lADRl 

o N o 

o N o 

O N G 

0 rNi 0 

PRINT 

55, 

oNo 

gNo 

cNg 

G N G ■ 

oNo 

PRINT 

65 , 

IADR2 

gNo 

g N o 

gNg 

^ N 0 

PRINT 

56 

o N 0 

oXg 

oXo 

0 N o 

0 N 0 

PRINT 

54, 

oNo 

lADRl 

I ADRl 

o N o 

oNo 

PRINT 

57, 

O N 0 

IADR2 

o N o 

o N o 

cNo 

PRINT 

67, 

oNo 

oNg 

I ADR2 

o N o 

cNo 

PRINT 

58, 

oNo 

oNg 

»Ng , 

IADR2 

IADR2 

PRINT 

54, 

oNo 

0 N o . 

O N G 

lADRl 

lADRl 

PRINT 

55, 

oNo 

oNo ■ 

oNg 

lADRl 

0 IM 0 

PRINT 

65, 

oNo 

oNo 

gNo 

gNg 

lADRl 

PRINT 

66 

oNo 

0 N 0 ' 

o N o 

gNg 

oNo 

PRINT 

59 

oNo 

oN, 

. gNg 

gXg 

0 X 0 

PRINT 

60 , 

.No 

oNg 

gNg- 

gNg 

0 N 0 

PRINT 

70, 

TMP 

TMP 

TMP ' 

TMP 

TMP 







INTGoEQol 
IREALoEQrl 
KSYMB oEQoNEG 

PRINT 51, IADR2 

PRINT 52 , „No 

PRINT 62, ,Nc 

PRINT 53, 

PRINT 63, ,No 

PRINT 5A, „No 

PRINT 55, „No 

PRINT 65 , oNo 

PRINT 56 ,• „No 

PRINT 5A, „No 

PRINT 57, „No 

PRINT 67, „N„ 

PRINT 58, „No 

PRINT 5A, oN„ 

PRINT 55, oN, 

PRINT 65, „No 

PRINT 66 „Xo 

PRINT 59 oNo 

PRINT 60, IADR2 

PRINT 70, oNo 

*TLEND 

51 FORMAT(10X,*CLA*,5X,A6) 

52 FORMAT(l0X,*ADD*,5X,A6) 

53 F0RMAT(10X,*SUB*,5X,A6) 

5A F0RMAT(10X,*LDQ*,5X,A6) 

55 FORMAT(lOX,*MPY*,5X,A6) 

56 FORMAT! 10X,*ZAC*) 

57 FORMAT(lOX,*DVP*,5X,A6) 

5 8 FORMAT! 1 OX, *AX0*,5X,A1 ,*-l , 1 *) 

59 FORMAT! 10X,*TIX*,5X ,7H*-1 , 1 ,1 ) 

60 FORMAT!lOX,*STO*,5X,A6) 

62 F0RMaT!10X,*FAD*,5X,A6) 

63 FORMAT! 10X,*FSB*,5X,A6) 

65 FORMAT(10X,*FMP*,5X,A6) 

66 FORMAT! lOX ,*CHS*) 

67 F0RMAT!l0X,*FDP*,5X,A6) 

70 F0RMAT!10X,*STQ*,5X,A6) 

IF!KSYMBoEQoNEG)GO to 100 
NT=NT+1 


CALL NEWT0P(TMP,MAIN) 

100 GO TO !20,30) ,KFLAG 

end 

/IBFTC number NOPRNO 

SUBROUTINE NUMBER 
INTEGER TEMP(5 ), PERIOD 
N=0 

INTEGER W0RD{72) ,PREV,CURENT;,BLANK 

INTEGER VNAME 

COMMON /CONNIE/ WORD , PREV , CURENT , I NDEX , BLANK 

COMMON /JOSIE/ IFlAG1,IFLAG2,IFLAG3,IFLAGA 


COMMON /SHEELA/VNAME 
DATA PERIOD/ 6 H 0 / 

DATA IPOWER/ 6 H' / 

IEXP=0 

IF(PREVoEQoIPOWER) IEXP=1 



10 CONTINUE 

*TABlE table For recognizing DECII4AL numbers in arithmetic 

-)s-TEXPR 

INTEGER C 
C=CURENT 

*THEAD 

NC=03sNR=0A,NA=08 ,RDEBUG»STAC0L 


EXPR 


>EQ„1 


SXDT05 
IFLAGl 
IFLAG2 
CURENT 
N “N + 1 
TEMP ( N) =C 
CALL SCAN 
CALL CI'AR 
CA-LL DIGIT 
PRINT 13 
IFLAG3=1 
GO TO lo 
*TLEND 

15 FORMAT ( IX, TERROR 
WRITE(99,20 ) 

20 F0RMAT(7X) 


,EQol 


,Xo 

>Xo 

>Xo 

3 X O 

.Xo 

3 N 0 

3 N 0 

3 X 0 


o N o 
oNo 
0 X 0 
0 X 0 
^Xc 
0 X 0 
oNo 
0 X 0 


oEG, 
o EQ , 
oEQ< 

0 X 0 

0 X 0 

0X0 

0X0 

cXo 

O N o 

oNo 

0X0 


0 

PERIOD 


o EQ o 0 
oEQoO 

oNEoPERIOD 
O N Q 
o N o 
O N o 
o N o 
o N o 

O N o 

0 X 0 

oNo 


Illegal character in decimal number*) 


WRI TE ( 99 , 25 ) ( TEMP ( I ) , I = 1 ,N ) 

25 F0RMAT{1H=,5a1 ) 

READ{99,30)VNAME 
30 F0RMAT(A6) 

IF( IEXP=EQo1)READ(99,35 IVNAME 
35 F0RMAT(1X,A6) 

return 

END 

/IBFTC IFcART 

SUBROUTINE IFART 

INTEGER W0RD(72) ,PREV , CURENT , BLANK 

Common /connie. lord ,prev,curent, index, blank 

COMMON /JOSIE/ IFlAGI , IFLAG2 , I FLAG3 , IFLAGA 
dimension S ( 6 ) ,T ( 6 ) ,STN0( 3 ) 

DATA LFPARjRTPAR ,C0MMA/6H( ,6H) ,6H, / 

integer RTPAR, COMMA, S,T,STN0 

IFLAG5=0 

data S/6H20OOOO,6H020O0O,6HoO 2O0C. ,6Hooo2on ,6 Ho0002o ,6Ho 00002/ 
CALL SCAN 
INIIA =0 


*TA6lE 

*THEAD 

table 

FOR 

recognizing 

Arithmetic <if' statement 

SXDT06 

CURENT 

NC = 0A 
0 EQ 0 F 

,NR = 

03 ,NA=08 jRDEBUG, STACOL 
oNEoLFPAR 

PREV 

IFLAG2 

INITA 

oEQo I 

» E Q 0 0 


e E Q 0 F 

0 E Q 0 0 

©EQ ©RTPAR 
©EQ©1 

WORD ( INDEX 

oNo 


©N© 

-2) =BLANK 

IFLAG5=1 

0 N 0 


oN© 

©Xo 

INDEX=9 

©No 


©N© 

©X© 

CALL AFITH 

©No 


©Np 

©Xo 

CALL SCAN 

0 X 0 


©No 

oX© 

CALL DIGIT 

©No 


©No 

oX© 

GO TO lo 

oX© 


©No 

© N © , ' , 

RETURN 

©N© 


©X© 

©N© 


*ELSE 


INITA=1 
CALL SCAN 
CALL DIGIT 
GO TO 10 

*TLEND 


N = 1 

WRITE(99,12) 

12 FORMAT (6X).' 

^^TABi E table For the Code generation of arithmetic 'I 

*THEaD 


SMDT0 2 NC=03 5.NR = 03 , NA= 10 s RDEBUG , STACOL 

CUrEnT oEQc, comma o£q„BlANK oNE^COMMA 


IFLAG2 

CURENT 

CALL SCAN oXo oN<, 

CALL DIGIT oXo oN^ 

WRITE( 99 9 20 ) ( T ( I ) 5 1 = 1 sK ) oNo 
READ(99925) STNO(N) oNo 

N”N+1 oXo oNo 

PRINT 19 „No oNo 

K=0 o X o o N o 

GO TO 30 oNo oX» 

NO TO 15 oNo oNo 

GO TO lA oXo oNo 

*ELSE 

K = K+1 


o EO o 0 

oNFoBLANK 

oXo 

o X o 
9 N o 

o N o 
oNo 
«Xo 
oNo 
o N o 

oXo 
o N o 


1 (K)=CURENT 
CALL SCAN 
CALL DIGIT 
GO TO 15 

*TLEND 

20 F0RMAT(6a1) 

25 FORMAT(A 6 ) 

30 DO 35 1=1,3 
WRITE(99»31)STN0(I) 

31 FORMAT(A 6 ) 

N = 1 

READ(99,32) (T( J) ,J=1,6) 

32 F0RMAT(6A1) 

DO 33 M=1»6 

IF(T(M) oNE.,BLANK)G0 to 33 
GO TO 35 

33 N=N+1 

35 STN0( I )=0R(S(N) sSTNOC I ) ) 

PRINT 36,STN0(1) 

36 FORMAT! 10X9*TMI*,5X»A6) 

PRINT 379STN0(2) 

37 FORMATIIOX^'^TZE^sSXsAB) 

PRINT 38 ,STN0(3 ) 

38 FORMAT! 10X»*TRA*,5X9A6) 

RETURN 

END ■ .. 

/IBFTC GOTO 

SUBROUTINE GOTO 

DATA LG0T0/6HG0T0 /' 

INTEGER .TEMP! 6 ) sCOMMAsSTNO! 10) »S! 6 ) 
data LFPAR 9 COMMA/ 6 H 

data LFPAR,RTPAR,C0MMA/6H{ . _ ^ 


F ' STATEM^ 


DO 10 1=1,4 
CALL SCAN 

10 TEMP( I )=CURENT 

WRITE(99,15) (TEMP( I ) ,1=1,4) 

15 F0RMAT(4a1) 

READ{99,20)NAME 

20 FORMAT (A4) 

IFLAG6=0 

IF ( NAME oNEoLGOTO) RETURN 
IFLAG6=l 

^^TABLE 

*THEAD 

SXDTrS NC = 0l ,NA = 01 ,NR = 02 

CURENT oEQoCOMMA oEQoLFPAR 

GO TO 30 oNo oXo 

*ELSE 

PRINT 21 

21 FORMAT! IX, *ERR0R-ILLEGAL' 'GO TO' STATEMENT*) 
RETURN 

*TLEND 

CALL SCAN 
CALL DIGIT 
CALL number 
WRITE(99,22)VNAME 

22 FDRMAT(A6) 

RE AD (99, 23) (TEMP( I) ,1=1,6) 

23 F0F>.AT(6a1) 

N = 1 

DO 25 M=l,6 

IF(TEMP (M) oEQoBLANK)GO TO 26 

25 N=N+1 

26 VNAME=0R(S(N) ,VNAME) 

PRINT 27,VNAME 

27 FORMAT! 10X,*TRA*, 5 A6) 

30 CALL DIGIT 

N = 0 

40 CONTINUE 

*Ta8LE 

*THE/'D 


SMDTu3 

NC=02,NR=03, 

NA = 07 


PREV 

oEQoLFPAR 

oEQoCOMMA 

oEQoRTPAR 

IFLAG2 

oEQol 

oEQol 


CALL NUMBER 

oXo 

o X e 

oNo 

N =N + 1 

oXo 

oX.. 

o N o 

STN!N)=VNAME 

o X o 

®Xc 

O N 0 

CALL SCAN 

© X o 

oXo 

oNo 

CALL DIGIT 

o X o 

o X o 

o N © 

CALL IDFIER 

©No 

oNo 

oX© 

GO TO 40 

*tlend 

o X o 

o X o 

oN© 

IF! IFLA63oNEoO)GO 

o 

m 

o 

1 — 




PRINT 45 I 

^5 ForMAK IX, TERROR- ILLEGAL =ARIABLE NAME IN COMPUTED 'GO TO' ST 

lENT*) I 

return 

50 PRINT 55,VNAME 

55 F0RMAT( 10X,^-^LAC*,5X,A6,*,1*) 

PRINT 60 

60 FORMAT(10X,*TRA*,5X,3h*,1) 

DO 7o 1 = 1, N 

K = 1 I 

DO 65 M = 1 ,6 I 

IF ( TEMP ( M.) oEQcBLANK ) GO TO 7o ! 

65 K=K+1 I 

70 STNO( I )=OR(S{K ) ,STNO( I ) ) | 

DO 75 1=1, N i 

75 PRINT 80,STNO(I) j 

80 F0RMAT( 10X,*TRA*,5X,A6) | 

RETURN 

end 

/entry 
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